Typical file caching methods include a cache receiving a file from a file server, and storing the entire file. Later when a client desires the file, instead of serving the file from the file server, the file is served from the cache. Because the cache is typically a server that is closer to the client, or has higher bandwidth than the file server, the file is served to the client quickly from the cache.
This can be understood with reference to FIG. 1, which is a schematic illustration of an exemplary architecture of a network 10 having an origin server 11 and a number of caches 12-16. Clients 17-19 are configured to receive files and/or streaming data from the origin server 11 or the caches 12-16.
In order to reduce the load on the origin server 11 and to save bandwidth in the delivery network 10, some of the content is stored in caches 12-16 closer to the end users 17-19. It is desirable to push these caches as close to the end user as possible.
For example, as shown in FIG. 2, mobile network architectures generally comprise a Core Network (CN) 200, to which are attached a number of radio access networks (RANs) in which terminals 231 to 238 are connected to radio base stations (RBSs) 221 to 224. The terminals may move and as they move they may be connected wirelessly to different RBSs. The transmission links between the RBSs and the rest of the network are usually rented and limited in capacity. One way of reducing the demands on these links is to use caching and, as described above, caching should preferably take place as close to the terminals as possible to minimize the need for transmission. For example, there may be caches 218, 219 at the radio network controllers (RNCs) 211, 212, caches 227 to 229 at the RBSs, and/or caches 209 in the core network 200. These may be controlled by a cache manager 202 in the core network 200, which organises the content stored in each of the caches to minimise the load on the network. It will be appreciated that this example is specific to a typical WCDMA RAN but it is illustrative of the situation in other systems as well.
One problem of caching in the RAN (with the cache being part of or co-located with the RBS, RNC, UE or any other RAN node) is that servers more distant from the client than the cache node are unaware of the data transfer that has occurred. This means that data monitoring nodes 203 in the core network, such as a service aware charge and control (SACC) or lawful intercept (LI) node, cannot monitor the content transmitted to the client.
One possible solution to this is to have only a single, centralised cache 209 connected to a monitoring node 203, which records the content transmitted to each client. However, this gives up the advantages of having a distributed cache in nodes closer to the client.
Another option is to distribute the monitoring functions between all cache nodes, however this would require a large scale redesign of all monitoring functions. It would also require interfacing with an arbitrary number of proprietary caching solutions, making the design of such functions more complex, expensive and difficult to maintain. Alternatively, all data requested from a cache node could be mirrored to the central monitoring node 203; however this would increase the transmission load on the network significantly. The cache could report details of the file, such as the size, filename, and type, to the monitoring node 203, or a mirror cache closer to the monitoring node 203 which can then transmit a copy of the file to the monitoring node 203. However, for lawful intercept purposes, it may not be possible to prove beyond reasonable doubt that the file served to the client was the same as that stored in the mirror cache due to the possibility of a mismatch between the local cache and the mirror cache.
Methods that can allow reliable centralised content access monitoring while still preserving the advantages of a distributed cache are thus of importance.